Mitigating security vulnerabilities in web content

ABSTRACT

Methods and apparatus are described for automatically modifying web page source code to address a variety of security vulnerabilities such as, for example, vulnerabilities that are exploited by mixed content attacks.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit under 35 U.S.C. 120 as aContinuation of U.S. patent application Ser. No. 15/791,291, filed on2017 Oct. 23, which is a Continuation of U.S. patent application Ser.No. 14/502,893, filed on 2014 Sep. 30, the entire contents of which arehereby incorporated by reference for all purposes as if fully set forthherein. The applicant(s) hereby rescind any disclaimer of claim scope inthe parent application(s) or the prosecution history thereof and advisethe USPTO that the claims in this application may be broader than anyclaim in the parent application(s).

BACKGROUND

Web sites and applications are vulnerable to attack by malicious thirdparties. One class of security vulnerabilities relates to the fact thata web page may include content or resources from a number of differentsources. If any of the resources loaded by a web page uses an unsecurechannel (e.g., an unencrypted network connection), a “man-in-the-middle”attacker (e.g., someone who has access to the unsecure channel betweenan end user's browser and the server delivering the web page) caneavesdrop or inject his own malicious content that can rewrite orotherwise alter the content of the web page; including delivery ofmalware to the end user. For example, if all of the resources associatedwith a web page are loaded via secure channels but the fonts are loadedusing a plain text connection, an attacker can overwrite the fonts witha payload that can take advantage of vulnerabilities in browsercomponents responsible for font handling. These kinds of vulnerabilitiesare commonly referred to as “mixed content” vulnerabilities. Sometechnologies, e.g., browser security directives, have been developed tomitigate some attack vectors, but many of these solutions are difficultto understand, implement, or maintain.

SUMMARY

According to various implementations, computer-implemented methods,systems, and computer program products are provided that enable theautomated modification of web page source code and/or HTTP headers toaddress a variety of security vulnerabilities. Source code and one ormore headers corresponding to a web page requested by a client deviceare received. The source code is rendered to generate rendered code. Therendered code is processed to identify one or more securityvulnerabilities. One or both of the source code and the one or moreheaders is/are modified to address the one or more securityvulnerabilities thereby generating modified code. The modified code istransmitted to the client device.

According to some implementations, processing the rendered code includesidentifying an unsecure channel corresponding to a resource identifiedby the source code. According to a specific implementation, modifyingone or both of the source code and the one or more headers includesspecifying a security directive requiring use of a secure channel by abrowser on the client device to access the resource. According to a morespecific implementation, it is determined that the resource supportscommunication via the secure channel. According to another specificimplementation, modifying the source code includes inserting first codein the source code, the first code being configured to access theresource via a secure channel. According to another specificimplementation, the resource is caused to be hosted in a secure serveror domain, and modifying the source code includes rewriting the sourcecode to access the resource at the secure server or domain.

According to some implementations, processing the rendered web pageincludes identifying an executable script in the source code. Accordingto specific implementation, modifying the source code includes rewritingthe source code to remove the executable script and causing theexecutable script to be hosted in a secure server or domain.

According to some implementations, modifying one or both of the sourcecode and the one or more headers includes specifying an X-Frame optionsheader, or inserting frame-breaking code in the source code.

According to some implementations, a determination is made as to whetherone or more modifications to the source code would result in the webpage being undeliverable to the client device.

According to some implementations, a report is generated specifying theone or more security vulnerabilities. The report is transmitted to arepresentative of a web site operator from which the web pageoriginated. Authorization is received from the representative of the website operator to proceed with modification of one or both of the sourcecode and the one or more headers.

According to some implementations, modifying one or both of the sourcecode and the one or more headers includes specifying one or moresecurity directives for use by a browser on the client device.

A further understanding of the nature and advantages of variousimplementations may be realized by reference to the remaining portionsof the specification and the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a simplified diagram of a computing environment in whichparticular implementations may be practiced.

FIG. 2 is a simplified diagram of a computing platform in whichparticular implementations may be practice.

FIG. 3 is a flowchart illustrating operation of a particularimplementation.

DETAILED DESCRIPTION

Reference will now be made in detail to specific implementations.Examples of these implementations are illustrated in the accompanyingdrawings. It should be noted that these examples are described forillustrative purposes and are not intended to limit the scope of thisdisclosure. Rather, alternatives, modifications, and equivalents of thedescribed implementations are included within the scope of thisdisclosure as defined by the appended claims. In addition, specificdetails may be provided in order to promote a thorough understanding ofthe described implementations. Some implementations within the scope ofthis disclosure may be practiced without some or all of these details.Further, well known features may not have been described in detail forthe sake of clarity.

This disclosure describes techniques that involve the automatedmodification of web page source code and/or HTTP headers to address avariety of security vulnerabilities such as, for example, those that areexploited by mixed content attacks. Before being delivered to arequesting client, the web page source code is rendered and analyzed toidentify security vulnerabilities. Such vulnerabilities might includethe use of an unsecure channel for accessing additional resources andcontent that may be located at external locations or hosted by theprimary application on the same domain, a subdomain, or an alternatedomain that is owned by the primary application. Other securityvulnerabilities might include, for example, the lack or insecureconfiguration of an X-frame options HTTP header, the lack of controlover whether a resource is allowed to be rendered within an <iframe>element, etc. Once identified, the security vulnerabilities areaddressed by appropriate modification to the web page source code and/orthe HTTP response headers. This might involve any of a variety ofactions to harden the source code before it can be transmitted to andrendered by the client. It might also involve specification of browserdirectives (via source code modification or modification of HTTPresponse headers) to be enforced by the requesting client browser.Specific implementations will now be described with reference to theaccompanying figures.

FIG. 1 illustrates an example of a computing environment 100 in whichweb page source code and/or HTTP headers may be modified for the purposeof addressing various security vulnerabilities. In this environment, oneor more servers 104 serve web pages via a network 108 to one or moreclient devices 112. Network 108 represents any subset or combination ofa wide array of network environments, including the internet, publicnetworks, private networks, local area networks, TCP/IP-based networks,telecommunications networks, wireless networks, cable networks, etc.Client devices 112 include any device capable of requesting web pagesserved by server(s) 104. For instance, such devices might include adesktop computer, a laptop computer, a tablet, a smartphone, a set topbox, a wearable computing device, etc.

A load balancer 116 (or multiple such load balancers) acts as anintermediary between servers 104 and network 108, distributing sourcecode (e.g., web pages served by servers 104) to one or more networkappliances 120. Network appliance(s) 120 process at least a portion ofthe source code received, identifying security vulnerabilities, andmodifying the source code and/or associated headers accordingly. Networkappliance(s) 120 provide the modified source code to requesting clientdevices 112 via load balancer 116 and network 108. According to variousimplementations, network appliance(s) 120 may be deployed in a varietyof locations including, for example, in the network of primary contentprovider associated with the web pages being served, in a ContentDelivery Network (CDN), in the network of an ISP, etc. Implementationsare also contemplated in which the various functionalities describedherein are implemented in any of a variety of devices that work togetherto deliver web pages to client devices including, for example, thevirtual and/or physical servers from which the pages are served, loadbalancers, routers, etc. The scope of this disclosure should thereforenot be limited by reference to some of the specific implementationsdetails described herein.

A simplified block diagram of an example of a network appliance 120 inwhich some implementations may be implemented is shown in FIG. 2.Appliance 120 includes one or more processors 200, including one or moresingle or multi-core processors configured to execute storedinstructions. Appliance 120 also includes one or more memories 204.Memory 204 includes computer-readable storage media that may include anyof a wide variety of forms of volatile and non-volatile storage media.For example, memory 204 could include electronic storage media, magneticstorage media, optical storage media, quantum storage media, mechanicalstorage media, etc. Memory 204 provides non-transitory storage forcomputer readable instructions, data structures, program modules andother data for the operation of appliance 120.

Appliance 120 also includes one or more network interfaces 208. Networkinterface(s) 208 may be used to connect via wired or wirelessconnections to cellular networks, including the internet, publicnetworks, private networks, local area networks, etc. For example,network interfaces 208 may include modules for a T-carrier such as a T1or T3 line, an optical carrier line such as a line to a synchronousoptical network or a fiber optic network, an Ethernet connection, adigital subscriber line, a telephone line, a coaxial cable, etc. Networkinterfaces 208 might also include radio frequency modules, e.g., for a3G or 4G cellular network, a WiFi local area network, a Bluetoothprivate network, etc. Appliance 120 also includes one or more buses orother internal communications hardware or software (not shown) thatallow for the transfer of data and instructions between the variousmodules and components of the appliance.

While appliance 120 might have many functions, this disclosure focusesmainly on the use of appliance 120 to modify source code and/or HTTPheaders associated with a web page for the purpose of addressing varioussecurity vulnerabilities associated with the web page. According to someimplementations, appliance 120 receives input code 212 (e.g., web pagesource code and associated HTTP header(s) through one or more networkinterfaces 208. The input code 212 is processed by a series of modules.While the number and variety of modules will vary depending on thespecific implementation, the modules relevant to the depictedimplementation are discussed below. It will be understood that these andother modules may be implemented by processor(s) 200 executing code inmemory 204.

It should also be noted that, despite references to particular computingparadigms and/or software tools herein, the computer programinstructions with which implementations within the scope of thisdisclosure are implemented may correspond to any of a wide variety ofprogramming languages, software tools and data formats, and be stored inany type of volatile or nonvolatile, non-transitory computer-readablestorage medium or memory device, and may be executed according to avariety of computing models including, for example, a client/servermodel, a peer-to-peer model, on a stand-alone computing device, oraccording to a distributed computing model in which various of thefunctionalities may be effected or employed at different locations ordifferent devices. In addition, reference to particular protocols hereinare merely by way of example. Suitable alternatives known to those ofskill in the art (including those later developed) may be employedwithout departing from the scope of this disclosure.

Referring again to FIG. 2 and to the flowchart of FIG. 3, a request fora web page generated by a browser operating on an end user's clientdevice is intercepted by appliance 120 (302). Appliance 120 generates arequest for the web page to the URL to which the original request wasdirected (304), e.g., a URL associated with one or more of servers 104of FIG. 1. The source code and associated header(s) of the web page(e.g., input code 212) are received by rendering logic 216 (306) whichmight be, for example, a “headless” browser (i.e., a browser thatoperates without a graphical user interface). Alternatively, logic 216may be configured to analyze raw HTML, JavaScript, CSS, and other webcontent using a variety of techniques including a combination oflexical, syntactic and/or semantic static analyses. It should be notedthat implementations are contemplated in which the appliance need notintercept the request from the client. Instead, the request could reachthe web server but the response to the request including the web pagesource code could be intercepted by appliance 120.

Rendering logic 216 renders the web page source code (308) in much thesame way as a conventional browser, e.g., identifying and loadingcontent from specified resources, executing inline scripts, etc. Thisresults in rendered code that a conventional browser would normallydisplay. Instead, code analysis logic 220 processes the rendered sourcecode to identify one or more security vulnerabilities (310). One or morecontent hardening actions may then be taken by content hardening logic224 to address at least some of the identified security vulnerabilities(312). The hardened source code (e.g., output code 228) is thendelivered to the requesting client (313).

According to a particular implementation, analysis of the renderedsource code includes building a source list of specified resources thatare accessed by the page's source code (e.g., by examining the headersassociated with the calls to the specified resources). As will beunderstood, the specified resources can correspond to any of a widevariety of objects, files, code, etc., including, for example, scripts(e.g., JavaScript, VBScript, Dart, etc.), styles (e.g., CSS styles),images, fonts, and containers (e.g., resources that can render variouscontent types, e.g., flash files, pdfs, media files, etc.). The codeanalysis logic determines for each of the specified resources whether itrepresents one of a plurality of security vulnerabilities. Examples ofsuch security vulnerabilities include but are not limited tocommunication via unsecure channels (e.g., clear text vs. encryption),injected scripts, UI redress, cross site scripting flaws, etc.

Content hardening actions include any of a variety of actions foraddressing the identified security vulnerabilities. Content hardeningactions may include modifications to or transformation of the sourcecode of the web page before transmitting it to the requesting clientdevice. Content hardening actions may also include modification of thesource code and/or HTTP header(s) to specify browser directives to beenforced by the browser on the client device (e.g., Content SecurityPolicy (CSP) directives, cookie directives, HSTS directives, etc.). Somecontent hardening actions may be specified, implemented, and/or enforcedas described, for example, in the Content Security Policy Level 2, W3CLast Call Working Draft (3 Jul. 2014) from the World Wide Web Consortium(W3C) (the “CSP working draft”), the entire disclosure of which isincorporated herein by reference for all purposes. Some examples will beinstructive.

As discussed above, a security vulnerability might be that a specifiedresource that the page's source code accesses communicates via anunsecure channel. In such a case, the content hardening action mightinclude probing the resource to determine whether it supportscommunication via a secure channel and, if so, rewriting thecorresponding references in the web page source code to connect withthat resource via a secure channel (e.g., via HTTPS). Alternatively, ifthe resource does not support communication via a secure channel, thecontent hardening action may include downloading the content from theresource (e.g., to appliance 120 or an associated secure server) andrewriting the references in the web page source code to request thecontent from its new location via a secure channel.

Instead of or in addition to inline modifications of the source code, aset of browser directives may be specified by modification of the sourcecode and/or associated HTTP header(s). For example, a directive could bespecified to require the use of HTTP Strict Transport Security (HSTS)which enforces the use of HTTPS connections to specified resources,i.e., if a browser receives a web page with this feature enabled, itwould not allow plain text connections to the specified resources.Another browser directive might enforce the transmission of cookies onlyover secure channels.

In another example, a browser directive could be specified thatprohibits the browser from executing any inline script or,alternatively, only allows execution of script from specified sources.As another alternative, the content hardening logic could rewrite theweb page content such that legitimate scripts would no longer be inline.This may be accompanied by the hosting of the scripts (e.g., byappliance 120 or an associated secure server or domain) and specifyingcontent security policy headers preventing the execution of inlinescripts. Such scripts may also be consolidated in a single trustedsource. According to some implementations, scripts or other resourcesthat are hosted separately from a rewritten page may be verified usinghash values to ensure that a copy of code or content received is valid.Such hash verification may be accomplished, for example, as described inthe CSP working draft incorporated by reference above.

According to yet another alternative, a “use strict” JavaScriptdirective may be specified that requires that any JavaScript code in thesource code of a web page be executed in “strict mode.” Inserting “usestrict” at the beginning of a JavaScript file or function prevents arange of potentially problematic scripting practices including, forexample, the use of undeclared variables, the deletion of a variable, afunction, or an argument, the duplication of a parameter name, etc.

The HTTP headers associated with received web pages may also be examinedto ensure that they correspond to a “white list” of headers/headertypes, or that they conform to one or more predefined canonical ornormalized forms. Non-conforming headers can be converted to anauthorized or normalized form. Enforcing the use of only authorizedheaders and/or header types prevents a wide range of attacks that relateto the introduction of or manipulation of HTTP headers.

Another security vulnerability might relate to so-called “click jacking”attacks that trick the user of a browser into taking actions he does notintend and of which he is unaware. For example, the user might bebrowsing a website www.site-x.com and a malicious operator of thatwebsite loads an invisible frame with content from websitewww.site-y.com, where user is already authenticated. While user thinkshe is interacting with www.site-x.com, the malicious script sends userinteractions to the invisible frame, i.e., the user unwittinglyinteracts with www.site-y.com. By specifying a directive that prohibitsbrowsers from loading www.site-y.com in a frame this kind of attack canbe prevented. Another content hardening action to deal with clickjacking attacks might be the insertion of a script commonly known as a“frame buster” into the web page source code, e.g., a script thatmitigates click jacking attacks by forcing the URL in the address bar ofthe browser to match the URL of the resource that is being forced toload in the main window rather than a frame.

In another example, a browser directive could be specified that requiresauthentication from specified resources accessed by a web page's sourcecode. For example, before loading a frame from one domain into a pagefrom another, such a directive could require authentication in the formof a checksum or hash (e.g., MD5 hash) that is unique to somecombination of information from the two domains.

Another form of hardening includes potential mitigations ofvulnerabilities in how SSL is applied. Misconfigurations of SSL andother web services can result in security vulnerabilities. The BREACHand CRIME attacks used properties of compression algorithms to revealsecret values (including session cookies and CSRF tokens). This securityintermediary device can be aware of common misconfigurations that resultin leakages. Using this knowledge it can reconfigure SSL and otherproperties of protected websites to prevent these attacks.

From time to time vulnerabilities, like Heartbleed, in widely usedsoftware libraries may become known. This network intermediary couldimplement remediations for these vulnerabilities without requiring anychanges to the protected web servers.

In addition to particular types of modifications and/or restrictions foridentified security vulnerabilities, implementations are alsocontemplated in which features or functions that are not employed by agiven web page are disabled for that web page.

It should be apparent from the diversity of the foregoing examples thata wide range of content hardening actions are contemplated foraddressing a similarly wide range of security vulnerabilities. The scopeof this disclosure should therefore not be limited by reference to suchexamples.

Referring again to FIG. 3, once the source code for a web page has beenanalyzed and its security vulnerabilities identified, the set of contenthardening actions may be cached (e.g., in memory 204 or another memoryaccessible to appliance 120) for use with that particular web page orwith a set of web pages from the same domain (314). For example, thiscached content hardening information may include a set of browserdirectives and/or other security countermeasures in the form of varioustypes of source code modifications. This information may then be usedfor hardening the same page or pages from the same domain in connectionwith subsequent requests. This reduces the computing resources requiredto harden web content (as indicated by the dashed line from 306 to 312),potentially reducing the latency associated with delivery of the pagesto the end user.

In addition to caching the set of content hardening actions, it may beuseful to cache other information. For example, it might be useful tocache the results of the processing of the rendered web page sourcecode, e.g., the one or more security vulnerabilities identified duringthe processing of the render code. Such information might be useful inidentifying or determining content hardening actions to take forsubsequent requests for the page that might not be available orappropriate for the earlier request. In another example, in which ahuman representative of a web site operator makes decisions aboutwhether and what types of content hardening actions should be taken,representations of such decisions can be cached for application tosubsequent requests.

According to a particular implementation, the content hardeninginformation for a given page or domain is cached only temporarily toensure that inappropriate modifications are not applied to laterversions of a page. For example, the information may be cached for thesame amount of time the source web site allows that same page to becached. This would provide some level of confidence that the source codeof the requested page is unlikely to have changed during that period oftime.

Such browser directives may include any rules or directives that wouldharden the security of the web page without breaking the functionalityof the web site. Before being applied, the information might be reportedto the web site operator for approval or authorization. However, thisstep is optional.

As will be appreciated, it is desirable that content hardening actionsnot interfere with the functionality of the web page for which thesource code has been modified. According to some implementations, theappliance may determine whether a particular content hardening actionwould have this effect, e.g., result in some or all of the web pagecontent not being deliverable. For example, the appliance mightdetermine that requiring the use of HTTPS would prevent some portion ofa web page from being delivered because the specified resourcecorresponding to that content does not support HTTPS. In such a case,the appliance might decide not to include that directive in the modifiedsource code. The appliance might also generate a warning relating to theidentified security vulnerability; possibly including the fact that itwas not addressed.

According to some implementations, appliance 120 may operate in areporting mode in which it generates reports for the web site operatorthat identify the security vulnerabilities in its web pages (316) (e.g.,the unsecure resources referenced by its web pages, vulnerable in-linescript, etc.) in order to give the web site operator the opportunity toapprove or authorize and/or select from among proposed content hardeningactions (318). For example, the web site operator might choose to haveunsecure content associated with specified resources hosted and servedby the appliance (or an associated secure server) as described above.Such reports may be generated even where automatic modification of atleast some of the web page source code is already taking place. Forexample, the web site operator might be notified when a new securityvulnerability has been identified before any further content hardeningaction is taken. Such reports to the web site operator might also beuseful for identifying when content retrieved from a specified resourcehas already been compromised. That is, manual inspection by a humanrepresentative of the web site operator can more readily identify, forexample, malicious scripts. If approval or authorization for contenthardening has not been given, the unmodified source code is delivered tothe requesting client device (320).

Examples of an original HTTP transaction (e.g., input code 212) andhardened code (e.g., output code 228) is provided below:

Input Code (Unmodified HTTP Response)

HTTP/1.1 200 OK Server: nginx Date: Tue, 15 Jul 2014 20:50:58 GMTContent-Type: text/html; charset=utf-8 Transfer-Encoding: chunkedConnection: close Vary: Accept-Encoding Expires: Mon, 26 Jul 199705:00:00 GMT Last-Modified: Tue, 15 Jul 2014 20:50:58 GMT Cache-Control:no-store, no-cache, must-revalidate Content-Encoding: gzipSet-Cookie:abc=0x56c990fd745b8a95;expires=Thu,14-Jul-2016 20:56:31 GMT;path=/Output Code (Modified HTTP Response)

HTTP/1.1 200 OK Server: Apache 2.2 Date: Tue, 15 Jul 2014 20:50:58 GMTContent-Type: text/html; charset=utf-8 Transfer-Encoding: chunkedConnection: (1)keep-alive Vary: Accept-Encoding Expires: Mon, 26 Jul1997 05:00:00 GMT Last-Modified: Tue, 15 Jul 2014 20:50:58 GMTCache-Control: no-store, no-cache, must-revalidate Content-Encoding:gzip Set-Cookie:abc=0x56c990fd745b8a95;expires=Thu,14-Jul-2016 20:56:31GMT; path=/;(2)secureContent-Security-Policy:  (3)default-src  https:;  (4)script-srchttps://cdn.example.com ; style-src https://cdn.example.com ;Strict-Transport-Security:(5)max-age=31536000;includeSubDomainsThe bolded sections of the output code indicate the content hardeningmodifications. The parenthetical numbers are inserted for the purpose ofidentifying the effect of each modification. For example, modification(1) enforces reuse of a TCP connection. Modification (2) requires thatcookies be sent only over a secure channel. Modification (3) requiresthe use of HTTPS for the main resource. Modification (4) enforces asource list of origins for scripts and styles based on the automaticanalysis of the main resource. Modification (5) requires use of HTTPStrict Transport Security, i.e., requires the client browser to use onlysecure channels to access the main resource and (based on automaticanalysis) possibly any subdomain resources as well.

Various implementations enabled by this disclosure provide protectionagainst a wide variety of attack vectors. And because it is possible tostore an understanding of a processed web site, additionalcountermeasures (including those that do not yet exist) can be appliedto web sites without additional analysis. Further, because the analysisis automatic, countermeasures can be applied at little or no marginalcost. This is to be contrasted with traditional web security whichrequires hours of skilled labor to apply and maintain suchcountermeasures.

Moreover, the techniques described herein allow developers and providersof web content to focus on delivering content and functionality ratherthan on mitigating security vulnerabilities. That is, security standardsare constantly evolving to keep up with the ever-changing securitythreat landscape. It is nearly impossible for the typical web developerto keep up with and incorporate best security practices into newlydeveloped web content. It is similarly impractical for providers of webcontent to continuously update previously developed and deployed webcontent to stay ahead of new security vulnerabilities. By contrast, thetechniques described herein (embodied, for example, in intermediarydevices such as network appliances 120) provide efficient mechanisms bywhich web content can be hardened, and in which new security standardsare readily integrated. Such techniques allow web developers and webcontent providers to focus on what they do best while, at the same time,giving them and their users the confidence that they are not vulnerableto attack.

It will be understood by those skilled in the art that changes in theform and details of the implementations described herein may be madewithout departing from the scope of this disclosure. In addition,although various advantages, aspects, and objects have been describedwith reference to various implementations, the scope of this disclosureshould not be limited by reference to such advantages, aspects, andobjects. Rather, the scope of this disclosure should be determined withreference to the appended claims.

What is claimed is:
 1. A computer system comprising: one or morehardware processors; at least one memory coupled to the one or morehardware processors and storing one or more instructions which, whenexecuted by the one or more hardware processors, cause the one or morehardware processors to: receive source code corresponding to a web pagerequested by a client device from a server device; process the sourcecode to identify one or more specified resources that are accessed bythe source code; determine that a particular resource of the one or morespecified resources is subject to a mixed content vulnerability, themixed content vulnerability comprising the source code allowing use ofan unsecure channel with respect to the particular resource; in responseto determining that the particular resource is subject to the mixedcontent vulnerability, modify the source code to specify a securitydirective instructing a browser on the client device to enforce thesecurity directive when the source code is executed on the clientdevice; cause transmission of the modified source code to the clientdevice.
 2. The computer system of claim 1, wherein the mixed contentvulnerability that the particular resource is subject to involves thesource code accessing the particular resource via the unsecure channel.3. The computer system of claim 1, wherein the mixed contentvulnerability that the particular resource is subject to involves thesource code loading a second web page in an invisible frame and sendinguser interactions to the invisible frame corresponding to the second webpage.
 4. The computer system of claim 1, wherein the mixed contentvulnerability that the particular resource is subject to involvesvulnerability in how SSL is applied with respect to compression.
 5. Thecomputer system of claim 1, wherein the security directive enforces useof a TCP connection.
 6. The computer system of claim 1, wherein thesecurity directive requires that cookies be sent only over a securechannel.
 7. The computer system of claim 1, wherein the securitydirective requires use of HTTPS Strict Transport Security.
 8. Thecomputer system of claim 1, wherein the security directive enforces asource list of origins for scripts and styles based on processing thesource code.
 9. The computer system of claim 1, wherein the one or moreinstructions, when executed by the one or more hardware processors,cause the one or more processors to: maintain security data comprising aplurality of security vulnerabilities that includes the mixed contentvulnerability and a plurality of security countermeasures correspondingto the plurality of security vulnerabilities; wherein determining thatthe particular resource is subject to the mixed content vulnerabilityincludes checking the particular resource for the plurality of securityvulnerabilities; wherein modifying the source code includes applying asecurity countermeasure of the plurality of security countermeasurescorresponding to the mixed content vulnerability.
 10. The computersystem of claim 9, wherein the one or more instructions, when executedby the one or more hardware processors, cause the one or more processorsto: receive data describing a new security vulnerability and a newsecurity countermeasure corresponding to the new security vulnerability;add the new security vulnerability to the plurality of securityvulnerabilities; wherein one or more resources are checked for the newsecurity vulnerability after the new security vulnerability is added tothe plurality of security vulnerabilities.
 11. A method, comprising:receiving source code corresponding to a web page requested by a clientdevice from a server device; processing the source code to identify oneor more specified resources that are accessed by the source code;determining that a particular resource of the one or more specifiedresources is subject to a mixed content vulnerability, the mixed contentvulnerability comprising the source code allowing use of an unsecurechannel with respect to the particular resource; in response todetermining that the particular resource is subject to the mixed contentvulnerability, modifying the source code to specify a security directiveinstructing a browser on the client device to enforce the securitydirective when the source code is executed on the client device; causingtransmission of the modified source code to the client device; whereinthe method is performed by one or more physical processors.
 12. Themethod of claim 11, wherein the mixed content vulnerability that theparticular resource is subject to involves the source code accessing theparticular resource via the unsecure channel.
 13. The method of claim11, wherein the mixed content vulnerability that the particular resourceis subject to involves the source code loading a second web page in aninvisible frame and sending user interactions to the invisible framecorresponding to the second web page.
 14. The method of claim 11,wherein the mixed content vulnerability that the particular resource issubject to involves vulnerability in how SSL is applied with respect tocompression.
 15. The method of claim 11, wherein the security directiveenforces use of a TCP connection.
 16. The method of claim 11, whereinthe security directive requires that cookies be sent only over a securechannel.
 17. The method of claim 11, wherein the security directiverequires use of HTTPS Strict Transport Security.
 18. The computer systemof claim 11, wherein the security directive enforces a source list oforigins for scripts and styles based on processing the source code. 19.The method of claim 11, further comprising: maintaining security datacomprising a plurality of security vulnerabilities that includes themixed content vulnerability and a plurality of security countermeasurescorresponding to the plurality of security vulnerabilities; whereindetermining that the particular resource is subject to the mixed contentvulnerability includes checking the particular resource for theplurality of security vulnerabilities; wherein modifying the source codeincludes applying a security countermeasure of the plurality of securitycountermeasures corresponding to the mixed content vulnerability. 20.The method of claim 19, further comprising: receiving data describing anew security vulnerability and a new security countermeasurecorresponding to the new security vulnerability; adding the new securityvulnerability to the plurality of security vulnerabilities; wherein oneor more resources are checked for the new security vulnerability afterthe new security vulnerability is added to the plurality of securityvulnerabilities.